filed patent application Ser. No. 09/477,047) with the addition of the following 
changes: 

DRAWING CHANGES 

In Figure 5, the output of the "EXECUTE VIA RCA" is returned to the "YES" 
output of the "GO?" block. 
Figure 9 is added 
Figure 10 is added 

SPECIFICATION CHANGES 

In the CIP at Page 12, line 8, the following sentence is added; 

"If it has executed a block of code, it will attempt to find another match 
and only returns control to the CCC when it finds no match." 

In the CIP at page 14, after line 16, the following paragraphs are added; 

"FIG. 9 shows an alternative embodiment of CCC 12. The first decision 
diamond GO 100 is simply for initialization and power on reset. If GO 100 is 
yes, the next block is the GO FLU 102 block. This means that the CCC has 
transferred control, the FLU which is active. The CCC is idled. The next 
decision diamond is GO 104 which idles while waiting for the FLU to transfer 
control back to the CCC. A yes output from decision diamond GO 104 indicates 
that control has returned to the CCC 12 and attention diamond 106 decides 
whether an exception 108 is to be executed. If attention diamond 106 has a no 
output then CCC executes an instruction in execution block 1 10. After die 
execution of the instruction the CCC makes a memory write decision in memory 
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write diamond 1 12. If the output is yes, an overwrite message 1 14 is generated. 
If the output is no then CCC 12 returns back to the yes output of the Go 100 
decision diamond. If an exception 108 is executed or an overwrite message is 
written a return is made to the input of GO FLU 102. 

Figures 4, 9, and 10 are alternative schemes for CCC flow. In each of 
these schemes, the CCC breaks from ordinary program execution at key points in 
order to advise the FLU of candidate code for replacement by logical functions, 
and to allow the FLU to execute logical functions it may already have in place of 
code immediately at hand. Each of these schemes has its advantages and 
disadvantages. 

FLU functions are limited in this invention to expressions or blocks of 
code involving registers only. Therefore, blocks of code to be replaced may not 
contain memory references. Figure 4 chooses to advise/consult the FLU after 
every transfer of control instruction, if and only if the next instruction to be 
executed is not a memory-referencing instruction. This is simple and efficient, as 
it guarantees a sequential block of 1 or more instructions eligible for replacement 
by a logical fimction every time the CCC yields control to the FLU, and control is 
yielded to the FLU only at the start of a candidate (or replaced) block. There are 
two disadvantages to this scheme, however: 1) Basic blocks which contain 
replaceable (register-only) code, but which start with a memory referencing 
instruction, will not be accelerated, and 2) It is necessary to read the fu^t 
instruction of the next block in order to determine if it accesses memory. 

Figure 9 addresses both of these issues by consulting the FLU prior to 
every instruction. This allows fiinctional replacements to be associated with any 
program counter address. The process which creates these functions replacements 
is then responsible to replace the appropriate register-only code, and to place the 
appropriate entry points in the FLU cache. This is an extremely simple solution. 
A disadvantage of this approach is that the FLU is consulted on every instruction, 
and depending on the processor implementation, this may be inefficient. Another 
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